软件开发安全设计原则

最小特权原则

对于请求存储资源的主体，只应该分配最少的必要权限，而且应该保证赋予权限分配的必要时间最短。如果授予一个用户或进程、组件超过其行为必要的权限范围的许可，该用户或进程、组件就有可能获得或修改其没有权限处理的信息。

权限分离原则

尽量把软件划分为不同的独立组件，把权限分成不同的权限许可和认证条件，用户授予不同的权限角色。不要将权限一次性授予一个用户，应该根据需要提供多重认证与检查机制再进行授予。

最少共享机制原则

避免多个主体共享同一个资源，因为敏感的信息可能通过相同的资源在这些主体之间共享，导致被其他用户获取。每个主体应该有不同的资源或不同的资源实例，在保证多用户存取访问灵活性的同时，防止由单一的共享机制导致潜在违背安全性的行为。

完全中立原则

每次主体对资源的请求，系统都应该实行认证和执行检查，特别是和安全相关的内容，以避免错误地赋予主体过高的权限，或者在第一次授予权限之后，主体被攻击之后攻击者滥用相关权限。为了提高性能，一些系统会缓存主体的权限，这种做法易使系统产生较高的安全风险。

心理可接受程度原则

安全机制应该尽可能对用户透明，只引入少量的资源使用限制，对用户友好，才能在使用时方便用户的理解和使用，真正起到安全防护的作用。如果安全机制妨碍了资源的可用性或使得资源难以获取，那么用户很可能会选择关闭这些安全机制或功能。

默认故障处理保护原则

当系统失效或产生故障时，必须是以安全的方式来处理系统信息，系统故障处理默认应该是安全的设置。例如，即使丧失了可用性，也应该保障系统的机密性和完整性；故障发生时必须阻止未授权的用户获得访问权限；发生故障后，应该不向远程未授权的用户暴露敏感信息，如错误号和错误信息、服务器信息之类。

经济机制原则

复杂性是评估一个系统安全性的重要因素之一。如果设计、实现的功能非常复杂，那么系统存在安全漏洞的可能性就会大大增加，一些问题在复杂的系统中很难被及时发现。系统的设计和实现应该尽量简单，以降低因复杂性带来的安全问题。

不信任原则

开发者应该假定系统环境是不安全的。减少对用户、外部系统、其他组件的信任，对外部实体所有的输入都需要进行检查。另外，也不应该认为每次对函数或系统的调用操作都会成功，必须对每次函数或系统调用返回值进行检查，并进行正确的处理。

纵深防御原则

软件应该设置多重安全措施，并充分利用操作系统提供的安全防护机制，形成纵深防御体系，以降低攻击者成功攻击的几率。多重安全措施使攻击者绕过每一个机制才能达到目的，提高了攻击者的攻击成本，降低了安全危害。

保障最弱环节原则

攻击者一般从系统最薄弱的环节发起攻击，而不是针对已经加固的组件。相对于破解一个数学上已经证明了比较安全的算法，攻击者更喜欢利用软件的安全漏洞。因此，软件开发者必须了解自己软件的薄弱点，对这些弱点实施更强的安全保护措施。

公开设计原则

应该假定攻击者有能力获取系统足够的信息，不能依赖于攻击者“不可能知道”来保护系统的安全。如果设计的加密算法存在弱密钥，或者系统设有万能口令等，攻击者通过反汇编分析能够获取这些信息，攻击者还可能是内部被辞退的员工，因此，依赖于攻击者无法掌握某些特定信息来保护系统的安全是不可靠的。

隐私保护原则

系统收集到的用户信息都必须实施妥善和安全的保护。攻击者获得了用户的隐私数据之后，可以进一步发起针对用户的各种攻击，如欺骗等，因此不应该向其他用户泄漏用户的隐私信息。

攻击面最小化原则

攻击面（attack surface）通常也称受攻击面，是指对一个软件系统可以采取的攻击方法的集合。因为攻击者对软件的攻击是通过其暴露在外部的接口、功能、服务和协议等资源来实施的，通过对每种资源计算其被攻击成功的可能性，并将这些可能性综合归纳，即可以衡量软件的攻击面大小。可以看出，一个软件的攻击面越大，其安全风险也就越大。

减少攻击面是安全设计中的一个重要步骤，软件设计人员需要仔细评估软件中所有的功能模块和接口的特性，分析其可能存在的安全风险，并设定相应的限制措施。如果一个功能/数据接口不是必要的，则应该取消或禁止，或者默认不开启。如果一个功能/数据接口的配置没有特殊的理由，则默认应该按安全的方式进行设置。